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(54) Method and system for resource reservation in a multicasting network 



(57) The present invention provides a method for 
operating a network system and a network system op- 
erated correspondingly for improving network resource 
reservations and allocations. Information included in 
signaling messages of a given protocol, like the re- 
source reservation protocol (RSVP), which do not pro- 
vide information about the actual communications sta- 
tus in the network. According to the invention, informa- 
tion concerning the communications/service quality of 
the network are collected from allover the network. In 
particular, such information is collected from all network 



domains and their routers, respectively. The collected 
information is communicated in the network by extend- 
ing the signaling messages obtained on the basis of the 
given protocol. Utilizing the collected information, serv- 
ice quality negotiations between a server and its client 
are improved. This improvement can be achieved for 
network systems comprising a network domain serving 
a single client, and multicasting networks. Furthermore, 
the present invention provides a solution for pre-reser- 
vation of network resources which avoids an unneces- 
sary reservation of network resources and a waste of 
network resources for subsequent resource allocations. 




Printed by Jouve, 75001 PARIS (FR) 



1 



EP 1 211 851 A1 



2 



Description 

BACKGROUND OF THE INVENTION 

1 . Technical Field 

[0001] The present invention relates to a method for 
improving communications between senders and re- 
ceivers via a network, such as servers, routers, and cli- 
ents communicating via the Internet comprising routers 
by extending signaling messages of a protocol used for 
the network and a communication system operated by 
the method according to the invention. 

2. Background of the Invention 

[0002] The Resource Reservation Protocol (RSVP) is 
specified by the Internet Engineering Task Force (IETF) 
and used to provide the signaling to enable network re- 
source reservations and allocations to provide Integrat- 
ed Services. In particular, RSVP enables Guaranteed 
Services and Controlled-Load Services. In this manner 
it is possible, for example, to obtain a control and guar- 
antee of load for network resources/components, such 
as network domains, servers, clients, routers ; and com- 
munication links. Resources are reserved or allocated 
for unidirectional data flows. A detailed description of 
the RSVP can be found in the article "RSVP and Inte- 
grated Services in the Internet: A Tutorial" by P. P. White 
in IEEE communications Magazine, May 1997, p. 100. 
[0003] In RSVP the server sends a PATH-message to 
the client, containing a traffic specification (upper and 
lower bounds of bandwidth, delay and jitter). This mes- 
sage is used to store the path state in each node (e.g. 
router) to route Reservation-Request-(RESV)-messag- 
es in the reverse direction. On the way of the RESV- 
message to the client, each network checks the traffic 
specification and possibly filters the requirements ac- 
cording to the network capabilities and resource availa- 
bility (admission control). The traffic specification is re- 
ceived by the client, upon which the client returns a 
RESV-message to the server to reserve the resources 
between the client and the server. 
[0004] Since most traffic requiring reservations is de- 
livered to groups (e.g. TV), it is natural for the client to 
make the request for a reservation for a flow. This has 
the added advantage that different clients can make het- 
erogeneous requests for capacity from the same 
source. 

[0005] The primary roles of the PATH-message are 
first to install reverse routing state in each router of the 
network along the communications path, and second to 
provide clients with information about the traffic charac- 
teristics of the sender and end-to-end (sender-client) 
communications path to generate appropriate reserva- 
tion/allocation requests. The primary role of the RESV- 
message is to carry reservation/allocation requests to 
routers of the network along the distribution tree be- 



tween clients and senders, wherein the distribution tree 
can also be a connection between one server and one 
client. 

[0006] Fig. 1 provides a (simplified) overview of the 
5 RSVP signalling messages flows and the most impor- 
tant parameters in each of the messages. 
[0007] The most relevant information in the PATH- 
message is the TSPEC of the sender defining the send- 
er traffic characteristics. 

[0008] The ADSPEC is an optional object that the 
server may include in its generated PATH-messages in 
order to provide the clients with the characteristics of 
the end-to-end communications path. This information 
can be used by clients to determine the level of reser- 
vation required in order to achieve their desired end-to- 
end QoS. The parameters included in the ADSPEC may 
be updated at each RSVP-capable router along the path 
in order to present end-to-end values to the clients. 
Some of the parameters are e.g. the minimum path la- 
tency, summation of individual link latencies, the path 
bandwidth, and the minimum of individual link band- 
widths along the path. 

[0009] RSVP supports both unicast and multicast 
sessions. The flow descriptors specify the QoS, which 
is used by participating entities, such as routers, server 
and clients. Hosts use RSVP to request a QoS level from 
the network on behalf of an application data stream. 
Routers use RSVP to deliver QoS requests to other rout- 
ers along the path(s) of the data stream. RSVP is able 
to adapt to changes in routing. 

[0010] A simplified overview of the operation of the 
RSVP is given in the following. 

[0011] Servers characterize outgoing traffic in terms 
of upper and lower bounds of bandwitlr delay, and jitter. 
RSVP sends a PATH-message from the server that con- 
tains this traffic specification (TSPEC) information to the 
destination address (unicast or multicast receivers). At 
reception of a PATH-message an RSVP capable router 
creates a PATH -state and stores the last hop address 
from the PATH-message and the TSPEC-information in 
the PATH-state. The last hop address is used for the 
routing of the RESV-message afterwards. Additionally 
RSVP capable routers may update the ADSPEC-infor- 
mation to contain end-to-end relevant parameter val- 
ues. 

[0012] To make a resource reservation/allocation, cli- 
ents send a RESV-( reservation request)-message up- 
stream. In addition to the TSPEC, the RESV message 
includes a request specification (RSPEC) that indicates 
the type of integrated services required and a filterspec- 
ification (FilterSPEC), that characterizes the data pack- 
ets for which the reservation is being made. (e.g. the 
transport protocol and port number). Together, the 
RSPEC and FilterSPEC represent a flow-descriptor that 
routers use to identify each reservation. 
[0013] When each RSVP router along the upstream 
path receives the RESV-message, it uses the admission 
control to authenticate the request and allocate the nec- 
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essary resources. If the request cannot be satisfied (due 
to lack of resources or authorization failure), the router 
returns an error backto the client. If accepted, the router 
sends the RESV upstream to the next router. When the 
last router receives the RESV and accepts the request, 
it sends a confirmation message back to the client. 
There is an explicit tear-down process for a reservation 
when a sender or receiver ends an RSVP session. 

Token Bucket Metaphor 

[001 4] RSVP is based on the token bucket metaphor, 
which turns an uneven flow of packets from the user 
processes inside the host into an even flow of packets 
onto the network, smoothing out bursts and greatly re- 
ducing the chances of congestion. Inthis manner, acon- 
trolled load can be provided throughout the network. 
[0015] Token bucket related parameters, which are to 
be defined fortheTSPEC-information, include peak rate 
of flow (bytes/s), bucket depth (bytes), token bucket rate 
(bytes/s), minimum policed unit (bytes), and maximum 
datagram size (bytes). 

RSVP and Integrated Services 

[0016] RSVP enables so-called Integrated Services, 
of which there are two fundamentally different types: 
Guaranteed Services: A guaranteed service comes as 
close as possible to emulating a dedicated virtual circuit. 
It provides firm (mathematically provable) bounds on 
end-to-end queuing delays by combining the parame- 
ters from the various network elements in a path, in ad- 
dition to ensuring bandwidth availability according to the 
traffic specification parameter in the PATH-message. 
[0017] Controlled-Load Services: A controlled-load 
service is equivalent to "best effort service under un- 
loaded conditions". 

[0018] Integrated services uses a token-bucket model 
to characterise its input/output queuing algorithm. This 
is, as an example, beneficial in case of a variable bit- 
rate video codec. The token-bucket parameters "bucket 
rate", "bucket depth", and "peak rate" are part of the 
TSPEC- and RSPEC-information. 
[0019] RSVP provides the highest level of Internet 
Protocol Quality of Service (IP-QoS) available. It allows 
an application to request QoS with a high level of gran- 
ularity and with the best guarantees of service delivery 
possible. However, the price for this is the complexity 
and overhead, and thus is overkill for many applications. 

Multicasting 

[0020] Multicast is the efficient transmission of an In- 
ternet Protocol (IP) datagram to a set of zero or more 
hosts identified by a single IP destination address. 
[0021] IP multicast efficiently supports one-to-many 
and many-to-many transmission by enabling sources to 
send a single copy of a message to multiple recipients 



(indirectly identified by a single IP class-D multicast ad- 
dress) who explicitly want to receive the information. 
This mechanism is far more efficient than sending mul- 
tiple messages to each recipient simultaneously or 
5 broadcasting the message to all nodes on the network. 
IP multicasting is a natural solution for multi-party con- 
ferencing because of the efficiency of the data distribu- 
tion trees (spanning trees), with data being replicated in 
the network at appropriate points rather than in end-sys- 
tems. 

[0022] Multicasting is based on a series of specific 
protocols that "ride on top" of the existing ones to effi- 
ciently distribute data to all interested parties. With IP 
multicast clients do not need to know who or where the 
servers are to receive traffic from them. Servers never 
need to know who the clients are. Neither servers nor 
clients need to care about the network topology as the 
network optimizes delivery. 

[0023] Multicast is a receiver-based concept. Receiv- 
ers join a particular multicastsession group by informing 
the multicast router on their subnetwork (Internet Group 
Management Protocol, IGMP) and traffic is delivered to 
all members of that group by the network infrastructure. 
For delivery of a multicast packet from the source (send- 
er, server) to the destination nodes on other networks, 
multicast routers need to exchange the information they 
have gathered from the group membership of the hosts 
directly connected to them. There are many different al- 
gorithms and protocols to exchange this routing infor- 
mation, such as Distance Vector Multicast Routing Pro- 
tocol (DVMRP), Multicast extension to OSPF (MOSPF), 
and Protocol Independent Multicast (PIM). Based on the 
routing information obtained through one of these pro- 
tocols, whenever a multicast packet is sent out to a mul- 
ticast group, multicast routers will decide whether to for- 
ward that packet to their network(s) or not. Finally, the 
leaf router will see if there is any member of that partic- 
ular group on its physically attached networks based on 
the IGMP information and decides whether to forward 
the packet or not. 

[0024] If the sender layers its data (e.g. video or au- 
dio) stream, different receivers can choose to receive 
different amounts of traffic and hence different qualities. 
To do this the sender must code the data (e.g. video da- 
ta) as a base layer having the lowest quality being ac- 
ceptable and a number of enhancement layers, each of 
which adds more quality at the expense of more band- 
width. With video, these additional layers might increase 
the framerate or increase the spatial resolution of the 
images or both. Each layer is sent to a different multicast 
group and receivers thereof can individually decide how 
many layers to subscribe to. 

[0025] Fig. 2 shows an IP multicast scenario where a 
video stream is sent to four recipients (i.e. clients 1 , 2. 
3 and 4). Clients 1 and 2 have joined the group by in- 
forming multicast router R2 and clients 3 and 4 have 
done the same with multicast router R3. Client 1 re- 
ceives a base layer (white packets), e.g. a code opti- 
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mized for wireless environments, whereas client 2 re- 
ceives this base layer and an additional layer (gray 
packets) for a better video quality. Clients 3 and 4 re- 
ceive a different base layer (e.g. a wireline codec). 
[0026] To achieve an efficient transmission, a span- 
ning tree is constructed, that connects all members of 
the multicast group. Only one copy of a multicast mes- 
sage will pass over any link in the network between the 
sender (server) and multicast router R1 . Copies of the 
message will be made only where paths diverge at a 
router (here at routers R1 , R2 and R3). Note that the 
"merging" of multicast streams at traffic replication 
points (such as R1 , R2 and R3) involves complex algo- 
rithms. 

RSVP and Multicasting 

[0027] RSVP may be used for multicast transmission. 
The RSVP PATH message will follow exactly the same 
path as the stream itself also for multicast transmission . 
[0028] Fig. 3 shows the multicasting of the PATH mes- 
sage. The routers R1 , R2, and R3 have multicasting and 
RSVP capabilities. 

[0029] The sender periodically sends a PATH mes- 
sage for each data flow it originates. 
[0030] The RESV-message is sent by the recipients 
(clients 1,2,3, and 4) of the stream towards the source 
following the exact inverse path of the PATH-message. 
The stream itself is characterized by a filter, so a single 
reservation can apply to several streams (e.g. several 
sources in a conference), i.e. a shared reservation. This 
is reflected in Fig. 4. 

[0031] Fig. 4 shows that multiple reservations for a 
multicast stream can be merged. If, for example, client 
3 requires a low delay and client 4 is prepared to cope 
with more delay for the same multicast stream, then only 
the largest reservation (i.e. lowest delay) will be forward- 
ed upstream (i.e. from R3 to R1). The same applies in 
case e.g. client 3 wants to receive the base layer for a 
specific video codec, whereas client 4 wants to receive 
the base and an additional layer. 
[0032] At branch points (i.e. the routers R1, R2, R3) 
in the distribution tree (to be) reserved TSPECs of the 
branches are not the same. The (to be) reserved TSPEC 
of a branch closer to the server is given by the maximum 
of the (to be) reserved TSPECS of its direct successors 
(in the direction of the destination). 

Differentiated Services 

[0033] Differentiated Services (DiffServ) provide mail- 
ings within IP packet leaders to allow prioritization of 
traffic aggregates (i.e. "classes" of multiple flows). Diff- 
Serv is employed to design a simple architectural frame- 
work for QoS that can provide a variety of scalable end- 
to-end services access multiple separately adminis- 
tered domains with requiring complex inter-provide 
business arrangements or complex behaviors in for- 



warding equipment. 
Bandwidth Brokers 

5 [0034] A Bandwidth Broker maintains information re- 
lating to SLSes that are defined between a DiffServ do- 
main and its customers, where DiffServ domain denotes 
a region of shared trust, administration, provisioning, 
etc. Customers include local users as well as the adja- 

10 cent networks that provide connectivity to other parts of 
e.g. the Internet. The internals of a DiffServ domain are 
not relevant to its customers, as long as the external 
obligations are fulfilled. The Bandwidth Broker uses this 
SLS information to configure routers in the local DiffServ 

15 domain (mainly the edge routers), and to make admis- 
sion control decisions. The Bandwidth Broker is re- 
quired to keep track of QoS resources, make policy de- 
cisions based on SLS information, and communicate 
policy enforcement information to the edge devices 

20 within the DiffServ domain. Furthermore, the bandwidth 
broker establishes and maintains SLAs with neighbour- 
ing domains. 

[0035] The general idea is for a customer to buy from 
their provider a profile for higher quality service, and the 

25 provider polices marked traffic from the site to ensure 
that the profile is not exceeded. Where providers peer, 
they arrange for an aggregate higher-quality profile to 
be provided, and police each other's aggregate if it ex- 
ceeds the profile. 

30 [0036] In this way, policing only needs to be per- 
formed at the edges to a provider's network based on 
the assumption that within the network there is sufficient 
capacity to cope with the amount of higher-quality traffic 
that has been sold. 

35 [0037] Before marked packets (DiffServ) from a data 
source are admitted to a Diffserv domain, the source 
must signal its local Bandwidth Broker to initiate a serv- 
ice reservation. The potential source is authenticated 
and subjected to local admission control policies. If the 

40 service reservation is admitted locally, the Bandwidth 
Broker may initiate an end-to-end reservation request 
along thechain of Bandwidth Brokers in the DiffServ net- 
works to be traversed by the data flow. When a network- 
wide admission control decision has been made, the 

45 Bandwidth Broker will configure the routers in the Diff- 
Serv domain to support the requested service profile. 
The Bandwidth Broker allows separately administered 
DiffServ domains to manage their network resources in- 
dependently, yet still cooperate with other domains to 

50 provide dynamically allocated end-to-end QoS. 

Problems 

[0038] Currently, RSVP supports limited communica- 
55 tion/service quality negotiations between servers and 
clients. Only the resulting end-to-end bandwidth and 
ADSP EC-information related data are provided to the 
clients. This information may be used by the clients to 



55 



4 



7 



EP 1 211 851 A1 



8 



verify whether they would like to use the service with the 
indicated service quality characteristics. Other service 
quality characteristics, such as security, reliability, and 
actual jitter are missing and therefore not taken into ac- 
count for the service quality negotiation. Such service 
quality characteristics are missing from the ADSPEC- 
information and are thus not updated on the way from 
the serverto the client(s). As mentioned above, jitter in- 
formation is implicitly included in the PATH-message, in 
particular in the token bucket parameters, but any 
changes thereof are not considered. 
[0039] Moreover, no mechanisms are currently avail- 
able to efficiently collect information about the network 
domains (and clients) between the server(s) and client 
(s). 

[0040] Since no mechanism for information collection 
is available, there is also no mechanism to handle this 
in a more efficient way in case of multicasting for one- 
to-many or many-to-many service provisioning. Further, 
a service quality optimization with respect to high (er) pri- 
ority clients or servers is not available. 
[0041] Further, no mechanism exists to limit the 
number of wasted resource allocations in case of mul- 
ticasting. 

[0042] In order to overcome the existing problems of 
the prior art, the object of the present invention is to pro- 
vide a solution for improving communications in a net- 
work utilizing a resource reservation protocol, such as 
theRSVP. 

BRIEF DESCRIPTION OF THE INVENTION 

[0043] The basic idea of this invention is to collect in- 
formation by extending the signaling messages in a pro- 
tocol like the RSVP. Information is collected throughout 
the network, e.g. from all network domains and/or sub- 
networks, between servers and corresponding client(s). 
Any network component serving as a sender, e.g. serv- 
ers, notes, routers, may use the collected information to 
check the actual status of the network, to make service 
distribution decisions, to make service provisioning de- 
cisions (e.g. links in a proxy or gateway), etc. RSVP is 
just an example for a protocol for which the present in- 
vention can be utilized. Therefore, the mechanisms ac- 
cording to the invention described here can be applied 
to similar or comparable protocols. 
[0044] The present invention optionally extends ne- 
gotiation information between a server and respective 
clients which can be used by clients to decide on the 
acceptance of an overall service provisioning quality. 
[0045] In addition to an information collection forasin- 
gle-client case, the present invention is also applicable 
for multi-client cases wherein multicasting and/oraggre- 
gation of collected information is utilized. 
[0046] Moreover, a pre- reservation mechanism pro- 
vided by the present invention can be implemented to 
prevent wasted resource allocations and extensive sig- 
naling in case of multicasting and/or to improve the qual- 



ity of service for high priority clients. 
[0047] Thus, the present invention addresses an in- 
formation collection mechanism, quality of service ne- 
gotiations between a server and its client(s), and a pre- 

5 reservation mechanism of network resources, for sin- 
gle-client and/or multi-client applications, wherein in the 
case of a multi-client application multicasting and/or ag- 
gregation of collected information is possible. 
[0048] To achieve the underlying object, the present 

10 invention provides a method for improving resource res- 
ervations and allocations in a network operated by a giv- 
en signaling message protocol, e.g. the RSVP. Accord- 
ing to the given protocol, a sendersignal including send- 
er traffic characteristics information of a sender is gen- 
's erated and transmitted via at least one network. Accord- 
ing to the invention, network traffic characteristics infor- 
mation is included into the sender signal while being 
transmitted to obtain an extended sender signal. The 
network traffic characteristics information is indicative of 

20 traffic characteristics of the network. Further, network 
resources are reserved and/or allocated in dependence 
of the network traffic characteristics information. 
[0049] Furthermore, it is possible to receive the ex- 
tended sender signal by a receiver and to generate, in 

25 response thereto, a receiver signal according to the giv- 
en protocol including receiver traffic characteristics in- 
formation being indicative of traffic characteristics of the 
receiver. Additionally, the network traffic characteristics 
information is included into the receiver signal to obtain 

30 an extended receiver signal. As a result, network re- 
sources can be reserved and/or allocated in depend- 
ence of the network traffic characteristics information 
and the receiver traffic characteristics information. 
[0050] In order to further improve service quality ne- 

35 gotiations, it is possible to transmit the extended receiv- 
er signal to the sender, while updating the extended re- 
ceiver signal by including actual network traffic charac- 
teristics information during transmission. As a result, 
network resources can be allocated in dependence of 

40 the updated extended receiver signal. 

[0051] It is preferred to transmit the extended sender 
signal and/orthe extended receiver signal and/orthe up- 
dated extended receiver signal via at least one router 
and to include and/or update the network traffics char- 

45 acteristics information by including and/or updating in- 
formation being indicative of traffic characteristics of the 
at least one router. 

[0052] The reservation and/or allocation of network 
resources can also be performed by the sender in de- 

50 pendence from the signal received from the at least one 
network, and/or the receiver in dependence of the re- 
ceived extended sendersignal, and/orthe at least one 
router in dependence of the received signal received 
from the network. 

55 [0053] To implement a pre-reservation and/or pre-al- 
location mechanism, reservation and/or allocation infor- 
mation is included into the sender signal according to 
the given protocol. The reservation and/or allocation in- 
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formation is indicative of network resources to be pre- 
reserved and/or p re-allocated. Thus, it is possible to 
pre-reserve and/or pre-allocate network resources in 
dependence of the reservation and/or allocation infor- 
mation. 

[0054] Improved network information can be obtained 
by including actual reservation and/or allocation infor- 
mation into the extended sender signal including the 
reservation and/or allocation information, the actual res- 
ervation and/or allocation information being indicative of 
network resources actually pre-reserved and/or pre-al- 
located. 

[0055] In this case, it is preferred that the at least one 
router reserves and/or allocates available resources 
thereof in dependence of the reservation and/or alloca- 
tion information of the sender and includes the actual 
reservation and/or allocation information corresponding 
to the actually pre-reserved and/or pre-allocated router 
resources. 

[0056] For a client oriented resource reservation and/ 
or allocation, the receiver includes a reservation and/or 
allocation request into the extended receiver signal in 
dependence of the received actual reservation and/or 
allocation information. Here, the reservation and/or al- 
location request is indicative of network resources to be 
used for communication with the sender. 
[0057] As a result, it is possible to reserve and/or al- 
locate network resources in dependence of the reser- 
vation and/or allocation request in the extended receiver 
signal and/or the updated extended receiver signal. 
[0058] If routers are employed, the at least one router 
can reserve and/or allocate pre-reserved and/or pre-al- 
located router resources in dependence of the reserva- 
tion and/or allocation request in the signal transmitted 
from the receiver. 

[0059] As a further option, indicators being indicative 
of resource reservations and/or allocations can be in- 
cluded in the signals transmitted via the network (e.g. in 
the sender signal, the extended sender signal and/or the 
extended receiver signal). Here, it is possible to use an 
indicator with respect to at least one of the network re- 
sources whether a resource reservation and/or re- 
source allocation is performed for signals transmitted 
downstream to clients (e.g. (extended) sender signal) 
and/or for signals transmitted upstream to senders (e. 
g. an extended receiver signal). Since some of the pre- 
reserved and/or pre-allocated resources in response to 
signals transmitted downstream to clients may be re- 
leased upon a reception of related signals transmitted 
upstream to senders, such resources may be pre-re- 
served and/or pre-allocated in dependence of higher pri- 
ority resource reservation and/or allocation requests. 
Therefore, (extended) sender signals including reserva- 
tion and/or allocation information can include "minimum 
resource required" indicators. Resources exceeding 
this minimum resources can optionally be used with re- 
spect to reservations and/or allocations by higher prior- 
ity resource requests. As a result, a faster connection 



setup for transmissions in the network can be obtained, 
since respective resources have already been pre-re- 
served and/or pre-allocated. 

[0060] In order to avoid unnecessary use of network 
5 resources, pre-reserved and/or pre-allocated network 
resources exceeding the reservation and/or allocation 
request of the receiver are released. Here, it is possible 
that the at least one router releases its pre-reserved 
and/or pre-allocated resources in dependence of the 
10 reservation and/or allocation request in the signal trans- 
mitted from the receiver. 

[0061] However, signals transmitted upstream from 
the receiver (e.g. (extended) receiver signals) can spec- 
ify that all pre-reserved and/or pre-allocated resources 
15 remain reserved and/or allocated, orthat a maximum or 
a minimum thereof remains reserved and/or allocated. 
This procedure still leads to an improved quality of serv- 
ice and in particular provides a fast connection setup. 
[0062] Moreover, the present invention provides net- 
20 work system utilizing a given signaling message proto- 
col for network resource reservations and allocations, a 
sender, a receiver, and/or at least one network for con- 
necting the sender and the receiver are operated by one 
of the methods according to the invention. 

25 

BRIEF DESCRIPTION OF THE FIGURES 

[0063] In the following description of preferred em- 
bodiments, it is referred to the accompanying figures 
30 wherein: 

Fig. 1 shows RSVP signaling messages and param- 
eters thereof, 

35 Fig. 2 illustrates an IP multicasting network, 

Fig. 3 illustrates a PATH-message multicasting in a 
RSVP network, 

40 Fig. 4 illustrates a RESV-message inverse multicast- 
ing in the RSVP network of Fig. 3, 

Fig. 5 illustrates a network utilizing RSVP-messages 
extended according to the invention, 

45 

Fig. 6 illustrates a RSVP network utilizing RESV- 
messages extended according to the invention 
for inverse multicasting, and 

50 Fig. 7 illustrates a pre- reservation mechanism ac- 
cording to the invention in a RSVP network. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

55 [0064] As described above, senders, receivers, and 
communication means (routers) for routing communica- 
tions between the senders and the receivers in a net- 
work utilize reservation protocols in order to set up the 
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necessary network state and to support communica- 
tions and associated services between the senders and 
receivers. One example for such a reservation protocol 
is the resource reservation protocol (RSVP). The follow- 
ing embodiments are set forth with respect to the RSVP, 
however the underlying principle is suitable to improve 
other network reservation protocols, e.g. ST-II. 

Basic embodiment 

[0065] I n order to improve service quality negotiations 
between servers and clients communicating via a net- 
work utilizing the RSVP, the signaling messages of the 
RSVP, namely the PATH-messages and the RESV- 
messages, are extended/modified to include further in- 
formation being indicative of the actual status of the net- 
work and its network domains, respectively. This infor- 
mation is collected from all parts of the network used for 
communication between a server and a client. In addi- 
tion to the information collected for all respective net- 
work domains, it is contemplated that this information 
also includes information being indicative of the actual 
status of a server and its client(s). 
[0066] On the basis of the collected information, the 
server, the client(s) and routers of the network and/or 
network domains are enabled to check the actual status 
of the network and/or its domains, to control the distri- 
bution of services provided via the network, to control 
the provisioning of network services (e.g. links to a proxy 
or gateway), to perform service quality negotiations be- 
tween the server and its client(s), and to pre-reserve/ 
pre-allocate communication resources of the network. 
Such a procedure can be applied to both single-client 
and multi-client applications, wherein for the latter case 
multicasting and/or an aggregation of the collected in- 
formation is an additional option. 
[0067] Referring to a PATH-message of the RSVP, the 
traffic specification (TSPEC) thereof defining the traffic 
characteristics of a server is extended by information 
characterizing the actual traffic characteristic of the net- 
work, and in particular of the network domains between 
the server and its client(s) and their routers, respective- 
ly. Further, the TSPEC can be extended by traffic char- 
acteristics information of the client. It has to be empha- 
sised, that the TSPEC itself is not modified. 
[0068] The traffic characteristics information of the 
network and the client can be provided as information 
directly identifying the respective traffic characteristics. 
As an alternative, the traffic characteristic information of 
the network and the client can represent variations of 
the actual traffic characteristics of the network and the 
client with respect to previous traffic characteristics 
thereof. Such variations can be caused by a variation of 
communications resources of the network or the client, 
wherein such resource variations include an increased 
and a decreased resource availability. In particular, 
these variations can relate to previous traffic character- 
istics of same network components (e.g. network do- 



mains, routers, servers, clients, gateways, etc.) and/or 
to traffic characteristics of previous network compo- 
nents, i.e. network components located more upstream 
with respect to the direction of data communication. 

5 [0069] In general, messages of the RSVP are gener- 
ated by each network component (server, client, router) 
on the basis of a received message for forwarding the 
information thereof. Therefore, PATH-messages ex- 
tended as explained above can include either above 

10 type of traffic characteristics information of the network 
and the client(s) depending on the network component 
(server, router, client) forwarding the respective PATH- 
message. 

[0070] Further, ADSPEC-information of the PATH- 
'S message can be extended by other communication 
characteristics, such as security, reliability, and jitter in- 
formation. Comparable to the above traffic characteris- 
tics information . such further communication character- 
istics information are added to the ADSPEC-information 
20 of the server by the routers and the client(s). Again, the 
ADSPEC-information itself is not changed. 
[0071] In order to access the actual communications 
state of the network and the client(s), the traffic charac- 
teristics information collected while forwarding the 
25 PATH-message are added to the RESV-message re- 
turned from the client(s) to the server. In particular, the 
collected traffic characteristics information is added to 
the RESV-message according to the RSVP to extend 
the TSPEC thereof. An improved communication quality 
30 negotiation between the server and its client(s) can be 
achieved by further extending the TSPEC of the RESV- 
message with information being indicative of the result- 
ing end-to-end communication characteristics. Receiv- 
ing such an extended RESV-message, the server ob- 
35 tains substantial information of the actual communica- 
tions status and is enabled to adapt its communications 
(distribution) correspondingly, e.g. by modifying the dis- 
tribution of provided services. 

[0072] Since the client(s) is (are) also provided with 
40 information being indicative of the actual communica- 
tions status of the network and, in addition, of the server, 
the respective RESV-message can be generated con- 
sidering the received communications status informa- 
tion. If, for example, a client determines that the over- 
45 all communication quality (quality of service) is not ac- 
ceptable, the RESV-message will not be returned and 
thus no resource allocation for the respective commu- 
nication path between the client and the server is per- 
formed. 

50 [0073] Further, a service reject by the client can in- 
clude information indicative of reasons for the service 
reject. In response, the server can use such information 
for e.g. traffic engineering and/or network planning pur- 
poses. 

55 [0074] Moreover, as a further option, the RSPEC-in- 
formation and/or the FilterSPEC-information of the 
RESV-message communicated to the server can be ex- 
tended by further information being indicative of the 
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communication (quality) characteristics in a manner 
comparable to the ADSPEC-information of the PATH- 
message. 

Traffic characteristics information collection for a 
network domain serving a single client 

[0075] For the purpose of simplicity, the embodiment 
shown in Fig. 5 utilizes RSVP-messages only including 
respective TSPEC-information. 

[0076] As shown in Fig. 5. a communication path be- 
tween a server and a client is routed via routers R1 and 
R2 constituing the network domain serving the client. 
The server generates a PATH-message according to the 
RSVP and transmits the same to the router R1 . In order 
to indicate the type of mechanism, which is used or 
which is to be used, the PATH-message can be extend- 
ed accordingly. 

[0077] In response thereto, the router R1 processes 
the received PATH-message according to the RSVP. 
Assuming this processing results in a validity for the re- 
ceived PATH-message, the router R1 generates a con- 
ventional PATH-message including, according to the 
RSVP, the traffic characteristics provided by the server 
and updated routing information. Here it is pointed out, 
that this conventional PATH-message does not include 
any information representing the actual traffic charac- 
teristics of the network, so far. 

[0078] Further, the router R1 generates information 
which represent its actual traffic characteristics. Such 
information can include the maximal/average peak rate 
of flow, the available bandwidth, the actual delay, the 
actual jitter, the actual security level for data communi- 
cations, actual allocated resources, available buffer 
space, and the like. This traffic characteristics informa- 
tion of the router R1 is added to its conventional PATH- 
message such said a message PATH 1 is obtained. 
[0079] The PATH'-message is transmitted to the rout- 
er R2 which generates, in response thereto, a message 
PATH" in a manner comparable to the generation of the 
PATH'-message. 

[0080] The PATH"-message transmitted from the 
router R2 is received by the client. In case, the process- 
ing of the PATH"-message by the client is indicative of 
a communication/service quality being not acceptable 
for client, the client generates no RESV-message. 
[0081] In case, the PATH"-message is indicative of a 
communications/service quality being acceptable for 
the client, the client generates a RESV*-message. The 
RESV*-message comprises a conventional RESV-mes- 
sage according to the RSVP and, further the collected 
traffic characteristics information. In addition, the 
RESV*-message can include information representing 
the end-to-end characteristics calculated for the com- 
munications between the server and the client per- 
formed so far. 

[0082] As a further option, it is possible that the 
RESV*'-message received by the router R2 is extended 



by its actual traffic characteristics information and trans- 
ferred as a RESV*'-message to the router R1 . Compa- 
rable, the RESV*'- mess age is extended by the router 
R1 and transferred as a message RESV*"-message to 
5 the server. 

[0083] On the basis of the received RESV*"-mes- 
sage, the server is enabled to access the actual com- 
munications status of the network domain serving the 
client. It is pointed out that this collection of traffic char- 
ge acteristics information can be performed when a com- 
munications/service is to be provided to the client, or 
can be just used to collect such information without pro- 
viding communications/services. In order to inform the 
routers R1 , R2 and/or the client whether the collection 
15 of traffic characteristics information is performed prior to 
the provision of communications/services or just for an 
assessment of the actual network status, the server can 
transmit a respective information, e.g. an indicator. 



[0084] In order to provide communications/services 
between one or several servers and several clients, the 
above described multicasting is used for the message 

25 distribution. For the collection of traffic characteristics 
information, the PATH-messages from the server(s) and 
the routers of the (respective) network domain(s) are ex- 
tended as set forth above for the single client case. 
Therefore, the respective extended PATH-messages 

30 from the server to the clients 1,2.3 and 4 are not shown 
in Fig 6. 

[0085] As explained above, the RESV-message re- 
ceived by a serverfor a conventional RSVP multicasting 
comprises aggregated RESV-messages from the re- 
35 spective clients. This aggregation serves to merge mul- 
tiple reservations from several clients for a multicast 
stream. 

[0086] In order to obtain a RESV*-message (i.e. a 
RESV-message extended by traffic characteristics in- 

40 formation), an aggregation step is performed to provide 
the traffic characteristics information of the network do- 
mains serving the clients 1 , 2, 3 and 4 and the resulting 
communications/service quality for each end-to-end 
(server-client) connection. 

45 [0087] Assuming that the traffic characteristics of the 
connections (networks) between the router R2 and the 
client 1 , and the router R2 and the client 2 are the same, 
information being indicative of these traffic characteris- 
tics only need to be communicated to the server once. 

50 As a result, the RESV* 12 '-nnessage communicated from 
the router R2 to the router R1 only contains traffic char- 
acteristics information of the client 1 provided by the 
RESV* 1 -message, the traffic characteristics information 
of the client 2 provided by the RESV* 2 -message and, 

55 just once, traffic characteristics information related to 
the network domain comprising the router R2, and the 
clients 1 and 2. 

[0088] In case the traffic characteristics of the net- 
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works between the router R2 and the client 1 , and the 
router R2 and the client 2 are not the same, or in case 
the clients 1 and 2 are not comprised by the same net- 
work domain, the router R2 must determine the overlap 
of the respective traffic characteristics information and 
aggregate the traffic characteristics information accord- 
ingly. As an alternative, router R2 can also just select e. 
g. the traffic characteristics which are received first. 
[0089] This aggregation step is accordingly per- 
formed with respect to the router R3 and the router R1 , 
respectively, wherein the transmitted RESV*' 34 -mes- 
sage and the RESV*^ 234-message are extended by 
the respective traffic characteristics information of the 
network domains including routers R1 and R3. 
[0090] As a result, the RESV*"-| 2,3,4" messa g e re- 
ceived by the server can only comprise, beside the traf- 
fic characteristics information of the clients 1,2,3 and 
4 and the routers R1 , R2 and R3, traffic characteristics 
information of three network domains. 
[0091 ] As an option compared to the above described 
network-wide aggregation for network domains, it is 
contemplated to perform a network domain related ag- 
gregation. Here, aggregated traffic characteristic infor- 
mation per network domain is included in the messages 
transmitted in direction to the server. As a result, with 
reference to Fig. 6, the server receives a message in- 
cluding the traffic characteristics information of the 
RESVY and RESV* 2 -messages, of the RESV* 3 - and 
RESV* 4 -messages, and the RESV* 1j2 - and RESV* 34 - 
m ess ages. 

Pre- reservation of network resources 

[0092] As explained above, RSVP resource reserva- 
tions for a network or network domains are obtained by 
transmitting a respective ADSPEC-information com- 
prised by a PATH-message. The ADSPEC-information 
is received by the network or the network domains, and 
especially the routers thereof, to determine the level of 
resource reservation required for a desired server-client 
communication/service quality. For allocating the re- 
served resources, the routers utilize a RESV-message 
transmitted from the client to allocate the necessary re- 
sources. In particular, RSVP-routers along the upstream 
path (i.e. in a communication direction towards a server) 
receiving RESV-message(s) utilize an admission con- 
trol to authenticate respective resource request and al- 
locate necessary resources. If a router can not provide 
the requested resources (e.g. due to a lack of resources 
or authorization failures), the router returns an error 
message back to the client. If the resource request(s) 
can be satisfied, the respective router sends the respec- 
tive RESV-message(s) upstream to the next router. 
[0093] For example in the case of a multicasting 
RSVP system, the following procedure of pre-reserving 
resources prevents unnecessary resource reservations 
downstream from the server to the client and that e.g. a 
router close to the server can not provide the required 



resources for allocation resulting in error messages sent 
to the client. A particular effect decreasing the commu- 
nication/service quality (e.g. communication transmis- 
sion time) of such error messages sent back to the client 

5 is the release of allocated resources previously allocat- 
ed by routers arranged between the error message 
sending router and the client. Further, correct and prop- 
er processing of such error messages generated by dif- 
ferent clients is complicated. 

10 [0094] The pre- reservation mechanism shown in Fig. 
7 is enabled by the modification of the RSVP as de- 
scribed above. Beside the extension of the RSVP-mes- 
sages transmitted from the server and the client, as de- 
tailed above, the PATH-message of the server is extend- 

15 ed by a pre-reservation request. In Fig. 7, this extension 
is indicated by the index The pre-reservation request 
of the server specifies a resource type and the extend 
thereof to be reserved. 

[0095] Comparable thereto, the client extends the ex- 
20 tended RESV*-message generated as explained above 
by a allocation request. Here, the index "°" is indicative 
of the allocation request. 

[0096] Referring to the example shown in Fig. 7, the 
server requests 12 units of the specified resource type. 

25 Upon receiving the PATH-message, the router R1 de- 
termines whether he can satisfy this request. Since the 
router R1 is able to provide the requested resources, 
the router R1 pre-reserves 12 units. 
[0097] The router R1 generates a PATH°'-message 

30 extended by the above traffic characteristics information 
and the pre-reservation request. Although router R2 can 
only provide 8 units, which are reserved, the PATH°"- 
message of router R2 is generated and transmitted to 
the router R3. In contrast thereto, according to a con- 

35 ventional RSVP system, an error message would be re- 
turned to a client in responsetoa RESV-message there- 
of to indicate that a resource request can not be satis- 
fied. 

[0098] The router R3 is able to provide 4 units of the 
40 requested resource and reserved the same. Again, no 

error message is returned to the server, but a PATH°"- 

message is communicated to the client. 

[0099] Therefore, the client gets a communication/ 

service resource request which is agreed and confirmed 
45 by all routers R1 , R2 and R3 between the server and 

the client. 

[0100] Upon confirmation of the received resource re- 
quest, the client generates a RESV*°-message extend- 
ed as the explained above and including an allocation 

50 request. Since the received resource request indicates 
that 4 units of the requested resource type can be pro- 
vided for the overall communications connection be- 
tween the server and the client, the allocation request 
generated by the client indicates that four units of the 

55 requested resource type are needed and should be al- 
located by the routers R1 , R2 and R3. 
[0101] While transmitting the RESV*°'-, RESV*°"- 
and RESV*° m - messages, which include the above ex- 
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plained extensions by the routers R1 , R2 and R3 and Claims 
the allocation request of the client, each of the routers 
R1 , R2 and R3 allocate 4 units of the requested resource 
type and release the previously reserved units actually 
not needed. 

[0102] Further, messages transmitted upstream from 
the client and routers R1 , R2, and R3 (e.g. RESV* 0 '-, 
RESV* 0 "-, and RESV* 0 '"-messages) can include infor- 
mation specifying that all pre-reserved and/or pre-allo- 
cated resources remain reserved and/or allocated, or 
that a maximum or minimum pre-reserved and/or pre- 
al located resources remain reserved and/or allocated. 
This approach still results in an improved QoS. 
[0103] The pre-reservation/pre-allocation mecha- 
nism can be used to ensure that clients and/or servers 
having a high(er) priority will be provided with required 
resources. 

[0104] Additionally, it is contemplated that the server 
can extend his RSVP-message by information (e.g. in 
form of an indicator) representing an upper and/lower 20 
limit of resources to be re-reserved (maximum/minimum 
resource reservation indicator). 

[0105] Since some of the pre-reserved resources in 
response to a PATH 0 -message may be released upon 
the reception of the respective RESV*°-message ; such 
resources could be partly used by an allocation request 
having a higher priority. As set forth above, an indicator 
in each router is used to specify whether a resource res- 
ervation is an actual resource allocation in response to 
a RESV-message or a pre-reservation in response to a 
PATH-message. To specify the amount of pre-reserved 
resources which can be used to satisfy a higher priority 
resource allocation, the above minimum resource res- 
ervation indicatorcan be used. The amount of resources 
above the limit defined by this indicator can be optionally 35 
used to fulfill a higherpriority resource allocation request 
related to a different PATH -request. As a result, a com- 
munication connection related to the higher priority re- 
source allocation request can be setup faster since 
these resources have already been reserved and no 
separate reservation is required. 
[0106] Comparable to the maximum/minimum indica- 
tors of the PATH°-message, the RESV*°-message can 
specify a minimum and/or a maximum of resources 
(types) to be allocated. For example, the RESV*°-mes- 
sage specifies said all routers should provide the same 
minimum bandwidth, such that all bandwidth related re- 
sources of the routers unnecessarily reserved are re- 
leased. 

[0107] Especially the utilization of minimum resource 
indicators for the PATH 0 - and RESV*°-messages guar- 
anties said servers and/or clients having a higher priority 
are provided the required resources, since related high- 
er priority resource requests can be fulfilled and are not 
blocked by a reservation of resources. 55 
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A method for improving resource reservations and 
allocations in a network operated by a given sign- 
aling message protocol . the method comprising: 

generating a sender signal (PATH-message) 
according to the given protocol including send- 
er traffic characteristics information of a sender 
(server), and 

transmitting the server signal (PATH-message) 
via at least one network, 



characterized by 

including network traffic characteristics infor- 
mation into the sender signal (PATH-message) 
while being transmitted to obtain an extended 
sender signal (PATH '-message), the network 
traffic characteristics information being indica- 
tive of traffic characteristics of the network, and 
reserving and/or allocating resources of the 
network in dependence of the network traffic 
characteristics information. 

2. The method according to claim 1 , comprising: 

receiving the extended sender signal (PATH 1 - 
message) by a receiver (client), 
generating a receiver signal (RESV-message) 
according to the given protocol including re- 
ceiver traffic characteristics information being 
indicative of traffic characteristics of the receiv- 
er (client), 

including the network traffic characteristics in- 
formation into the receiver signal (RESV-mes- 
sage) to obtain an extended receiver signal 
(RESV*-message), and 

reserving and/or allocating resources of the 
network in dependence of the network traffic 
characteristics information and the receiver 
traffic characteristics information. 

3. The method according to claim 2, comprising: 

transmitting the extended receiver signal 
(RESV*-message) to the sender (server) via 
the at least one network, 
updating the extended receiver signal (RESV*- 
message) by including actual network traffic 
characteristics information while transmitting 
the receiver signal (RESV*-message), and 
reserving and/or allocating resources of the at 
least one network in dependence of the updat- 
ed extended receiver signal (RESV*'-mes- 
sage). 



4. The method according to one of the preceding 
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claims, comprising: 

transmitting the extended sender signal 
(PATH'-message) and/orthe extended receiver 
signal (RESV*-message) and/or the updated 5 
extended receiver signal (RESV*'-message) 
via at least one router (R1, R2, R3) of the at 
least one network, and 

including and/or updating the network traffics 
characteristics information by including and/or 10 
updating information being indicative of traffic 
characteristics of the at least one router (R1 , 
R2, R3). 

5. The method according to one of the preceding is 
claims, wherein: 

the sender (server) reserves and/or allocates 
network resources in dependence from the sig- 
nal (RESV*-message, RESV*'-message) re- 20 
ceived from the at least one network. 

6. The method according to one of the preceding 
claims, wherein: 

25 

the receiver (client) receives and/or allocates 
network resources in dependence of the re- 
ceived extended sender signal (PATH'-mes- 
sage). 

30 

7. The method according to one of the claims 4 to 6, 
wherein 

the at least one router (R1, R2, R3) reserves 
and/or allocates its resources in dependence 35 
of the received signal (PATH'-message, 
RESV*-message, RESV*'-message) received 
from the at least one network. 

8. The method according to one of the preceding 40 
claims, comprising: 

including reservation and/or allocation informa- 
tion into the sender signal (PATH -message) ac- 
cording to the given protocol, the reservation 45 
and/or allocation information being indicative of 
network resources to be pre-reserved and/or 
pre-allocated, and 

pre-reserving and/or pre-allocating network re- 
sources in dependence of the reservation and/ 50 
or allocation information. 

9. The method according to claim 8 ; comprising: 

including actual reservation and/or allocation 55 
information into the extended sender signal 
(PATH°'-message) including the reservation 
and/or allocation information, the actual reser- 



vation and/or allocation information being indic- 
ative of network resources actually pre-re- 
served and/or pre-allocated. 

10. The method according to claim 9, wherein: 

the at least one router (R1, R2, R3) reserves 
and/or allocates available resources thereof in 
dependence of the reservation and/or alloca- 
tion information of the sender (server), and 
includes the actual reservation and/or alloca- 
tion information corresponding to the actually 
pre-reserved and/or pre-allocated router re- 
sources. 

1 1 . The method according to one of the claims 8 to 1 0, 
wherein: 

the receiver (client) includes a reservation and/ 
or allocation request into the extended receiver 
signal (RESV*-message) in dependence of the 
received actual reservation and/or allocation 
information, the reservation and/or allocation 
request being indicative of network resources 
to be used for communication with the sender 
(server). 

12. The method according to claim 11 , comprising: 

reserving and/or allocating network resources 
in dependence of the reservation and/or alloca- 
tion request in the extended receiver signal 
(RESV*°-message) and/or the updated ex- 
tended receiver signal (RESV*°'-message). 

13. The method according to claim 12, wherein: 

the at least one router (R1, R2, R3) reserves 
and/or allocates pre-reserved and/or pre-allo- 
cated router resources in dependence of the 
reservation and/or allocation request in the sig- 
nal (RESV*°-message, RESV*° '-message) 
transmitted from the receiver (client). 

14. The method of claim 12 or 13, wherein: 

pre-reserved and/or pre-allocated network re- 
sources exceeding the reservation and/or allo- 
cation request of the receiver (client) are re- 
leased. 

15. A method according to claim 14, wherein: 

the at least one router (R1 , R2. R3) releases its 
pre-reserved and/or pre-allocated resources in 
dependence of the reservation and/or alloca- 
tion request in the signal (RESV*°-message, 
RESV*°'-message) transmitted from the re- 
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ceiver (client). 

16. A method according to one of the claims 11 to 15, 
wherein: 

5 

the receiver (client) includes information into 
the extended receiver signal (RESV*-mes- 
sage), the information being indicative of a 
maximum or a minimum of the pre-reserved 
and/or p re-allocated network resources to re- 10 
main reserved and/or allocated. 

17. The method of claim 16, wherein: 



18. 



19. The method according to one of the preceding 
claims, wherein: 



20. The method according to claim 1 9, wherein: 45 



22. The method according to one of the preceding 
claims, wherein: 

the given signaling message protocol is the re- 
source reservation protocol (RSVP), 
the sender signal (PATH-message) is the 
PATH -message of the resource reservation 
protocol (RSVP), and 

the receiver signal (RESV-message) is the 
RESV-message of the resource reservation 
protocol (RSVP). 

23. The method according to one of the preceding 
claims, wherein: 

the method is utilized in a network serving a sin- 
gle-client and/or a multi-client application. 

24. The method according to claim 23, wherein: 

the signals (PATH-message, PATH'-message, 
PATH°'-message) transmitted to the client(s) 
are transmitted by utilizing a multicasting trans- 
mission. 

25. The method according to claim 23 or 24, wherein: 

the signals (RESV-message, RESV-mes- 
sage, RESV* 1 -message, RESV*°-message, 
RESV*°'-message) transmitted to the sender 
(server) are transmitted by a utilization of an in- 
verse multicasting transmission. 

26. The method according to claim 24 or 25, wherein: 

an aggregation of information included into the 
signals transmitted via the network is per- 
formed with the respect to the at least one net- 
work and/or components thereof. 

27. A network system utilizing a given signaling mes- 
sage protocol for network resource reservations 
and allocations, comprising: 

a sender (server), 

a receiver (client), and 

at least one network for connecting the sender 
(server) and the receiver (client), wherein 
the sender (server) is adapted to be operated 
by the method according to one of the claims 1 
to 20. 

28. The network system according to claim 27, wherein: 

the receiver (client) is adapted to be operated 
by the method according to one of the claims 1 
to 26. 



the information included into the transmitted 
signals comprise an indicator specifying a min- 
imum of required network resources. 

50 

21. The method according to claim 20, wherein: 

pre-reserved and/or pre-allocated network re- 
sources exceeding network resources speci- 
fied by the indicator are used for at least one 55 
network resource request having a higher pri- 
ority. 



pre-reserved and/or pre-allocated network re- 15 
sources remain reserved and/or allocated in 
dependence of the information included into the 
extended receiver signal (RESV*-message) 
being indicative of the maximum or the mini- 
mum network resources to remain reserved 20 
and or allocated. 

The method according to claim 1 7, wherein: 

the at least on router (R1, R2, R3) maintains its 25 
pre-reserved and/or pre-allocated resources in 
dependence of the receiver information being 
indicative of the maximum or the minimum of 
network resources to remain reserved and/or 
allocated. 30 



the signals (PATH-message, PATH'-message, 35 
RESV-message, RESV*-message, RESV-- 
message, PATH°'-message, RESV*°-mes- 
sage, RESV*°'-message) include information 
being indicative whether a resource reservation 
and/or allocation is performed for a message 40 
transmitted in a direction to the receiver (client) 
and/or for a message transmitted to the sender 
(server). 
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29. The network system according to claim 27 or 28, 
comprising: 

at least one router (R1 , R2, R3) of the at least 
one network, the at least one router (R1 , R2, 5 
R3) being adapted to be operated by the meth- 
od according to one of the claims 4 to 26. 

30. The network system according to one of the claims 
27to29 : wherein: 10 

the given signaling message protocol is the re- 
source reservation protocol (RSVP). 
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